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Abstract 

The Curry-Howard correspondence is about a relationship between types and programs 
on the one hand and propositions and proofs on the other. The implications for pro¬ 
gramming language design and program verification is an active field of research. 

Transformer-like semantics of internal definitions that combine a defining computation 
and an application will be presented. By specialisation for a given defining computation 
one can derive inference rules for applications of defined operations. 

With semantics of that kind for every operation, each application identifies an axiom in 
a logic defined by the programming language, so a language can be considered a theory. 

1 Introduction 

The Curry-Howard correspondence relates programming languages and logic. Essentially it 
reflects similarity between propositions and proofs of a formal logic and types and programs 
of a programming language. W.A.Howard is the author of the seminal paper on the 
correspondence. Various researchers have investigated its implications for programming. 
Transformer semantics is just for a type of language design based on notions that relates 
to weak existence described by Howard separately in the same paper. 

According to the Curry-Howard correspondence, the notions of programs correspond 
to proofs, and a program proves its type according to the typing rules of the programming 
language. So a powerful notion of types is needed for this to be of interest. Per Martin 
Lof5 [4] has advocated a system with such a type system. 

Dijkstra’s predicate transformers can be molded as a logic, but the predicates in such a 
system do not correspond to types, but programs correspond to proofs, if their applications 
are seen as recordings of proof steps. Dijkstra’s language statement constructs have the 
trivial type void but in a language with a richer type system, typing rules would imply 
that programs seen as proofs would also prove the type of its result. 

A formal system which includes expressions of the form 3p9.R0 will be presented. These 
are mathematical expressions that combine the following parts: a program text P, a math¬ 
ematical expression Rg, and an operator 3p6. which might be compared to the integration 
operator / __ d9. The operator 3p9. binds free occurrences of 9 in the expression Rg (as in 
lambda-calculus, say). The intuitive meaning of the abstraction variable is an expression 
for the value obtained by interpretation of P. 3p9. is an automorphism on mathematical 
expressions, partly related to Dijkstra’s predicate transformers. 

The intuitive reading of 3p9.R0 is that P proves that an expression 9 exists such that 
R 0 ‘is of interest’. The objective with 3p9.R0 is similar to Dijkstra’s, i.e. to obtain a 


mathematical expressions that, in the state from which P should be interpreted, has the 
value of Re in the in the result state. 

The verb ‘to prove’ is transitive, but it is possible to conceive the noun ‘proof’ inde¬ 
pendently of an object as required by the verb. A proof can be understood as a pattern of 
references to individual rules of a formal logic. A programmer writes programs that can be 
seen as proofs, when an adequate language is used. Programmers do not need to master 
the logic aspects, but provide proofs much like people may do in every-day arguments. 
Such proofs may need be checked but, hopefully, may be automated some day. 

A beneht of programs as proofs is that not all programmers need to master the logic 
aspects of programs completely. One may still acknowledge programmers work as proofs 
in a substantial sense. Language designers should, of course, be more concerned with the 
rules for application of their operations, i.e. their adequateness as axioms of a logic. 

Another beneht might be the implicit enforcement of a programming discipline that is 
indirectly inhuenced by formal logic, much the same as discussions in daily life may beneht 
from rules justihed by formal logic. 


2 Transformation semantics 

Dijkstra has presented a notion of predicate transformers along with a simplihed program¬ 
ming language, and thus illustrated an important relationship between language design 
and a logic for program proofs: [2]. However, transformation rules appear to arise as ax¬ 
ioms from the intuition of the language designer. Dijkstra’s language does not support 
dehnitions in programs. But they are needed in practice and corresponding transfomation 
rules likewise. 

Rules for dehnitions within programs, and even inside dehnitions will be essential also 
to hnd rules for application of dehned entities. Such dehnitions will be called internal 
definitions. It will be possible to write them in familiar style, but conceptually they diher 
a bit: a dehnition is more like familiar (letrec- or) let-constructs, i.e. it combines one part 
that constitutes a conventional dehnition with an application part where the dehned entity 
can be applied. 

The notion of internal dehnitions in an adequate programming language that admits P 
in 3p6*. should allow dehnition of object-like entities, i.e. means to introduce ‘members’ 
associated with an ‘object’ of some ‘class’. An essential aspect is that programmers do not 
chose names of members, but accept names determined by the ‘class’. 

Such introduction of names can be generalised, and the term implicit name binding will 
be used for it as a design principle. Furthermore, ‘in-line dehnitions’ should be manda¬ 
tory, which can be done by admitting hrst-order types only. Higher-order entities will be 
admitted in another way. In other words: operation names may not be used as arguments 
and implicit name binding thus required for every ‘in-line dehnition’. 

An internal dehnition can be compared to a class with the dehned entity as its only 
member in the application part. Both notions combine details of semantics with a notion of 
abstraction over its application. Simula 67, [1], provides the inner notion for the ‘remaining 
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part of the current block’, like the scope of dehnitions in several other languages, e.g. Pascal 
and C. Simula’s inner notion will be replaced by a (named) parameter, and the idea is 
generalised so that implicit name binding may occur in several arguments. 

An essential difference for programmers, between classes and internal dehnitions, is the 
required description of ‘parameters’ in the latter. Identihcation of an internal dehnition 
includes the parameter description, over which one cannot abstract. Parameter descriptions 
will be structured like those of Pascal [7], but extended with type parameters. Higher-order 
parameters are then described by the same syntax as used for internal dehnitions. The 
term signature will be used for parameter descriptions. 

3 A combinator for internal definitions 

Several languages support a simple construct 

let f(x)= Expri in Expr 2 

where the name / can be used in Expr 2 for a function that maps x to Expri. It can be ex¬ 
plained reasonably well with lambda-notation by (A f.Expr 2 ){Xx.Expri), i.e. an expression 
that can be rephrased as follows: 

(A B.X A.{A{B))){Xx.Expri){X f.Expr 2 ) 

With no name occurring free, the expression XB.XA.{A{B)) is a combinator and can be 
given a global name, e.g. DEF: 

DEF {Xx.Expri) {Xf.Expr 2 ) 

which, except for a missing signature and the explicit introduction of names, forms an 
internal dehnition. A single argument combinator is appropriate for a global definition 
in agreement with mathematics, but not for internal dehnitions. This and the need to 
structure programs for human readers justihes internal dehnitions as a separate notion. 

Lamb da-calculus prescribe rewriting rules for expressions in lambda-notation. Here we 
just depend on the /3-rule: 

(A X. Expri) {Expr 2 ) = [x <i Expr 2 \ Expri 

where the right-hand side prescribes substitution of Expr 2 for x in Expri. However, a 
reservation is necessary to avoid unintended name binding, i.e. a free occurrence of a name 
in Expr 2 unintentionally getting bound in the process. A request for a name change in such 
situations is a typical way to state the reservation. Our use of the substitution symbol, <i, 
shall include this reservation. 

The following simplihed example illustrates DEF and use of the ,d-rule. However, it 
also illustrates that lambda-calculus is unht to render the proceedings in a way that is easy 
for humans to follow. The many lambda-abstraction is one essential cause. Another is that 
equational reasoning here blends the contexts of the two arguments where they should be 
kept apart to help readers. 
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DEF 

(XDXA.A(XX.D(X*2))) 

(Xr.rCXx. (x*x))(Xf. (f(3)))) 

= (Xr.rCXx. (x*x)) (X f. (f (3)))) 
(XD.XA.A(XX.D(X*2))) 

= (XD.XA.A(XX.D(X*2))) 

(Xx. (x*x))(Xf. (f(3))) 

= /• (f(3))) (X X. (Xx. (x*x)) (X*2)) 

= (XX. (Xx. (x*x)) (X*2)) (3) 

= (Xx. (x*x)) (3*2) 

= (3*2) *(3*2) 

= 36 


Notice that the character case of names in the two arguments of DEF differ: all capitalised 
in the hrst, none in the second. It reflects a simple ping-pong-like game of control. 

A programming language will be introduced in which an internal dehnition for the 
above can be expressed as: 

DEF r OF T [D [x:int]:inti] [A[f[X:inti]:int]:T]: T 
{ A{D{X*2}} } 

{ r{x*x}{f{3}} }; 

The text after DEF on the hrst line is a signature and contains enough information to 
avoid explicit parametrisation (i.e. the A-s). The third line illustrates use of the dehned 
operation r which itself has a structure similar to an internal dehnition: its hrst argument 
dehnes a function that is required to derive the function f used in the second argument. 

From a signature one can automatically derive a rule for application of the derived 
operation, i.e. r above: 


^ = ^Ej^0. -\ 

= ^Ei,0. H 



3f{£x}^- 


3,,,^. 3 


3x0. 



( 1 ) 


where Dr is the hrst argument of the internal dehnition. Before we see how such a rule 
helps to derive the result value we need to explain the structure. 

Rules have the form of equations or conclusion H presumptions and are displayed as: 


3Left0. 3i^igjit0. 3 


presumption-^ 

presumption 2 


Each presumption can be a rule. Presumptions do hold by assumption. 
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Box 1 Axiom schemes 


1. DEF-scheme 

^DEF f. . . {Df 

2. Annihilate 

3. Constant 

3c0. = [e<c] 


f [Pi. . .]i=i..jv/= 

i.e. error if 9 occurs free in the (omitted) operand 

with C a constant 


4. Subsumed name translation (i.e. used only without an explicit alternative) 

3x0. = [0 <1 A] NB: different fonts for X 


5. Sequential computation 
3£i;£20- = 3e^93e20. 

6. Infix operator symbols (with # varying over operator symbols) 

3 E^# £ 2 ^- ~ ^EiB.3£' 2 '^ 2 . [0 <1 (b 0 T 2 ]) where C identifie the meaning of # 


4 Formalisation of copy-rule semantics 

Semantics of internal definitions is formalised by a scheme of transformation rules that 
essentially formalises the copy-rule semantics of Algol 60 [5]. The formalisation will be 
called the DEF-scheme for brevity and it constitutes the only complex transformation rule 
that serves as an axiom. Copy-rule semantics for Algol 60 has been described intuitively 
in a few words, but its formalisation is complex. 

A version that covers only call-by-name parameters and with optional result types 
disregarded, forms an introduction to the general scheme. 


3 

3 


DEF f . . . {Bf}{£'f}0. — 3 


£f0. 

{D,E] 


( 2 ) 


Symbol = identihes a macro that combines a signature and a switch for control status, 
{D, i3}, which indicates alternation between dehnition- and application-contexts. This 
scheme is the interesting axiom of a logic of transformations. Box 1 presents all of them. 

The rules allow side-effects and imply call-by-name. Call-by-value can be covered as 
expressed for application of an operation with signature 


and semantics 


with OF T,W (X:T) [Body(__:T):W] : W 


3 


ith{£x}{£Body}^- - 

3Body{l>..}0. = - [—<Vl] ^EBody^- 
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Parentheses can be used in signatures to request call-by-value. The example illustrates the 
obvious: that the axiom schemes above do not suffice, and that substitution is not not a 
trivial operation. 

The form of internal definitions can be described with EBNF as 


“DEF” signature D_ “}” E_ “}” 

where signature = name { “[” signature “]” }i,,Ar [ : type ] and iV > 0 

Signatures will be described in greater details later. 

The DEF-scheme in Equation 2 tells that a definition of f combines two arguments 
Df and Ef, and that the entire construct as one expression is given by with a 

presumption about applications of /. 

Presumptions in the DEF-scheme tell that application of a name in one context is com¬ 
bined with a defining argument in the other. This combination represents the formalisation 
of the copy-rule, with their environment represented by presumptions. 

The complication of the DEF-scheme is expressed by the macro _ : 

f[ Pi [gij. . .]j=i..n, ]±=i..n/={D,E} ( 3 ) 

A tool can generate DEF-schemes from signatures. Even from more complex signatures 
that may contain call-by-value parameters, type expressions, and (possibly overloaded) 
signatures of operator symbols. 

A transformation rule for internal definitions is fairly complex. A one-step expansion 
of the def-macro in the presumption of Equation 3 may bring some relief: 


f [ Pi [gij. . .]j=l..n, ]i=l..N/= 

= 3 f{£ 6*. = Nf>0 


H 


3p, - ^Ep,0. 


H 




J j=l. .rii 


i=l..N/ 


( 4 ) 


Equation 4 expresses a presumption for application of DEF, which is a rule for applications 
of /. That rule is stated in terms of the unknown Df, the first argument of DEF, the 
presumptions of which are similar rules for application of operations Pi. Applications of Pi 
is stated in terms of unknowns Ep. (i.e. arguments of /). The presumption of Ep. are rules 
for applications of operations gj (i.e. implicitly introduced names) in terms of unknowns 

Eventually a rule reduces to a pattern of substitutions corresponding to: 


f<XPi.\P2.---.\PNrDf 


Ef 


[Pi <\\gi.Xg2. ■ ■ ■ .Xgni-Ep^] Df 


( 5 ) 
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The objective has been to obtain rules that do not use lambda-abstractions, but rather 
point-wise use of functions and implicitly introduced names. Reservations about unin¬ 
tended name bindings associated with <i apply for H also. 

An important issue related to Equation 3 is whether some language may satisfy the 
property. To see that, we characterise a language as follows 

• Every operation must have a signature 

• Application expression of the language has the form /{E'i}{E' 2 }...{E'n^} when the 
signature of / is 


[Pi 

bO 

1_1 

1-1 

(M 

hO 

1_1 

1-1 

[Sl,nl • • 

.]] 


[P2 

[g2,l • • 

■ ] [g2,2 • • • ] 

[g2,722 • • 

.]] 


[PNf 

[gVj-,1 

• . •] [gV/,2 • ■ 

• . • IgNf 

,nNf ■ 

. .] ] 


where Nf > 0 and > 0 

• Each application expression is interpreted as a lambda-expression 

= /(^.r(E0)(^.r(E2))...(A^^,.r(i^,)) 

where stands for Xgk, 2 ----><gk,nk 

T introduces lambda-abstractions for implicitly introduced names and in agreement 
with the bindings expressed in Equation 5 

• Each internal dehnition DEF signature {D}{E} is an application of combinator DEE 
equipped with signature 

signature Isignature] [App[signature] ] 

Let this language be called C. The terms Howard languages and Howard programs will be 
used for languages characterised like C and their programs, respectively. 

PROPOSITION 1 Language C satisfies Equation 2-4, if adequate means ensure that names 
are distinct. 

PROOF. The interpretation T implies that C is interpreted as a subset of lambda- 
expressions that satishes Equations 2-4 according to the correspondence stated in Equa¬ 
tion 5. QED 

For a given signature, transformation rules for applications may be derived — literally in 
case an internal definition actually exists and virtually in case a definition exists only in 
terms of some idealised Howard language. 

Derivation is by specialisation, which is similar to mathematical projection of a function 
of two variables by hxing the value of one. An alternative term in programming language 
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research is partial evaluation and it caries over to logic in agreement with the Curry-Howard 
correspondence [3]. The advantage of this approach is that programming details of some 
internal dehnition get eliminated by specialisation. Furthermore it gives credit to the use 
of prototypes in system development. 

It all means that every operation identihes a transformation rule for its application, and 
that program composition corresponds to combined use of inference rules. In this sense a 
program is a proof, with the only addition that recursion in a dehnition is an appeal to 
proof by induction. 

DEF-schemes can be considered key axioms of a logic with proofs encoded as Howard 
programs. Other axioms, all briehy described in Box 1 are rather trivial. 


5 Equational reasoning with presumptions 


A DEF-rule is an instance of a given signature’s DEF-scheme. Equation 1 illustrates such 
a DEF-rule, which is repeated here for your convenience: 




e. = 


3D{i3x}^- = H 


H{Di} 


o. = 3,,e. 


3^6. = 3ri^9. 

3,9. = 3,^9. 


( 1 ) 


Instantiation with £'d=x*x, £'A=f{3} and I)r=A{D{X*2}} we obtain: 


H 


x*x}{f{3}}^- = 3 a{D{X*2}}^- 

3J. = 3,J. 
3f{£:x}^- ~ ^Dfd- 


3d{Dx}^- ~ 3x*x^- 3 
3A{llf}^- = 3f{3}0. - 


3 [ 3,9. = 3e^9. 


Presumptions are unaffected by this initial step, but now we need to instantiate the sec¬ 
ond with Pf=D{X*2} to get a rule by which the right-hand side of the equation can be 
transformed: 


3 


H 


r{x*x}{f{3}}^- = 

3D{flx}^- = 
3A{Di}9. = 
3 A{D{X*2}}^- 


3 A{D{X*2}}^- 

3x6*. = 3ci^9. 


3x*x9. 3 
3f{3}6*. 3 

= 3f{3}0. 




9. = 3 


3 


3x^. = 3 

3f{£x}^- = 


3,9. 


Dfd. 

Eyi^- . 

= 3,^9. 


The presumptions now consist of the two from the general rule and one instantiated from 
one of these. We shall for brevity memorise the former to be instantiated when needed. 
However, when an instantiated presumption is used, its presumptions get introduced. 


































3f{Ex}^- ~ 3i3jx*2}^- 

_L 

1-1 

LU 

X 

LU 

X 

orb 


3d{£Ix}^- ~ 3x*x^- 3 

3x0. = 

3d{x* 2}^- h 

- 1 1 - 

LU : 

X 

LU 

CO 

5 b 

_ 1 



3x*x^- 3 

3x0. = 330. 




. 3x0. = 3x*20. . 



3x*2ri.3x*2'r2. [0 < (ri ■ T 2 )] 3 

_ 3x0. = 330 . . 




Continued transformation by rules for infix operators trivially leads to the value 36 in 
agreement with the lambda-calculus example (page 3). 


6 Language design and transformation semantics 

Dijkstra has introduced predicate transformers as semantics of a programming language, 
striving to establish programming as a discipline of mathematics. Semantics had before 
that mostly been presented as mathematical models, with the notion of state as a stumble 
point for mathematicians. The important advantage of using transformations is elimination 
of state changes, rather than explaining a process in terms of a sequence of states. 

Dijkstra’s semantics did not include dehnitions. Internal dehnitions as introduced above 
depend on context and their semantics is given by DEF-schemes. So Howard languages 
illustrate that transformation semantics can be expressed for languages more general than 
Dijkstra’s. 

A tool exists to implement Howard languages with support for a hxed, common syntax 
and the following concepts: 

• internal dehnition with signatures (of a fairly general notion of operations) 

• operation applications including inhx notation with operator symbols 

• usual notation for sequential composition of computations 

• type inference with types considered sets (in the mathematical sense) 

Essentially there are so few predehned operations that the core can hardly be classihed 
as a programming language. The tool helps introduce predehned operations from a given 
signature. 
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Support for one family of languages can be considered both negative and positive from 
a language designer’s point of view. Language implementers are restricted syntactically 
but provided with strong support for type checking and modularity. The tool represents 
a conservative choice of syntax and allows conveniences where a strict syntactic reflection 
of concepts is undesirable (e.g. ’declaration’ as a shorthand for an application). 

6.1 Semantics of signatures 

The term ‘signature’ is related to similar concepts in other programming languages, and 
some might easily and reasonably consider them essentially identical. Some consider it a 
simplihed version of a concept not yet clarihed and blame it for not covering semantics of 
the operation with a given signature. 

Before going on, recall that internal dehnitions are similar to classes while an item 
being dehned is similar to a member. Probably we agree that the semantics of classes and 
members should not be confused, so likewise we need to distinguish between semantics of 
an internal dehnition and the item being dehned. So: 

A signature encodes semantics of internal definitions+ 

Concretely it means that a signature can be translated into a transformation rule for 
possible instances of internal dehnitions with the given signature. 

6.2 Signatures and command syntax 

Signatures determine the syntax of named commands as given below in EBFN: a pair 
of braces contains patterns that can be iterated (or omitted), a pair of bracket contains 
patterns that can be omitted. Actual symbols appear in typed font between and 
characters. 

Signatures identified by names 

Signature = Name [ Typeinf ] { “[” Signature “]” } [ Type ] | 

Typeinf = “OF” [ Numeral ] Name { [ Numeral ] Name } 

Application syntax 

Expr = Name { [ Label [“:”]] Arg } | “ DEF” Signature Arg Arg 
Arg = Expr { Expr } 

The number of required arguments in an application is equal to the length of the list of 
signatures following the name in the operation’s signature. The syntax above is simplihed 
to emphasise the correspondence between signatures and arguments. Box 2 provides a 
more complete description. 

Convenience rules prescribe some special notations as identical to expressions that adhere 
to the syntax: 
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Box 2 Signatures and expressions 


Signature 

BasicSignature 
Identification 
TypeOperator 
T yp eExpression 

CbVSignature 

ValueList 

TypedSignature 


= BasicSignature | OpSignature | CbVSignature 

= Identification { “ [” Signature “] ” } [ “: ” TypeExpression ] 
= Name [ “OF” TypeOperator { TypeOperator }] 

= [ NaturalNumber ] Name 
= { Typ eExpression } Name 

= Identification ValueList { “ [” Signature “] ” } 

Typ eExpression 

= “(“ TypedSignature { TypedSignature } “)” 

= Identification [ ValueList ] “: ” TypeExpression 
I OperatorSignature 


OpSignature 

Operatorld 
Expression = 
Qualifier = 

Argument = 
ArgList = 

LevelName = 


= Operatorld “(“ TypeExpression TypeExpression “)” 
TypeExpression 

= OperatorSymbol [ “OF” TypeOperator TypeOperator} ] 
E I [ Qualifier “.” ] Name { Argument | ArgList} 

LevelName 

[ LevelName ] Expression Expression } [ 

[ LevelName ] “(“ Expression { Expression } “)” 

Name [ “:” ] 


E 

O 


Application | [0][E]{[E]0E}[E][0] 
OperatorSymbol 


A ?-symbol is assumed, if no other operator separates two expressions. 


“(” E “)” 


Identity is a braced, semicolon separated lists of expressions not being an argument of 
an application. Identities are are interpreted as arguments of a program operation 
which is a polymorphic identity. 

Declaration allows an application to be written with its last argument apparently miss¬ 
ing, but present as ‘the remaining part of a context’. This is often used to write 
an internal definition as in other languages, and similarly use common notation for 
instantiation of a class. 

Syntactic coercion allows a level name to be used by itself, provided a name for a default 
member is introduced in the argument it applies to. The default member name is 

by convention_ Further, when alse a name _ is introduced, the default member 

name may be replaced by that when used as a call-by-value argument, or according 
to descriptions of operator symbols. 

A list expression is a bracketed, comma separated lists of expressions. Such ar inter¬ 
preted as a : : separated lists of the expressions terminated by : :nil, with the 
operator symbol and nil being user defined. 
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Language designers who want mutable variables may provide an operation for their decla¬ 
ration with a signature like 

var OF w, rvalue [Scope OF lvalue 

(_:lvalue) 

[_:rvalue] 

[:=(lvalue,rvalue) : rvalue]:w]:w 

Operation var may be applied as in { var x; . . . ; x: =x+l; . . . } which will be disambig¬ 
uated as { var x{ . . . ; x. :=x._+l; ... ]- }, i.e. by taking ‘the rest of the brace’ as 

the missing argument in an application written as a ‘declaration’ 

6.3 Example: induction 

An operation can be dehned to match the structure of proofs by induction: 

induction OF Problem, Result 
[Initial:Problem] 

[Break_down[_:Problem] 

[result[Sub:Problem]:Result]:Result]:Result 

and it might be useful in exercises to teach programming with easy-to-prove iterations, 
e.g. to compute the product of elements in a list use 

inductionf [3,5,7] } L: { split_list{L}-{l}{hd*result{tl}}- } 

7 Specialisation 

A well-known example, twice, can be internally dehned and used as follows 

{ DEF twice [F[x:int]:int] [Return[f[X:int]:int] :int]:int 
{ Return{F{F{X}}} }; 

twice{x*x}; # i.e. F is x -> x*x with implicit x 
f{2> # so f(2) is (2*2)*(2*2) 

} 

So, although only values can be returned, it is possible to provide access to a function as 
a member, say ‘f’, of a class-like operation. The example uses the syntactic convenience 
rule for ‘declarations’ that makes it equivalent to 

{ DEF twice [F{x:int}:int] [Return [f{X:int}:int] :int]:int 
{ Return{F{F{X}}} } 

{ twice{x*x}{f{2}} } 

} 
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i.e. the apparently missing argument is taken as ‘the rest of the brace’. In this form there 
is no need for the outermost braces. 

It is bad to restrict the result of the entire computation to int. but the type systems 
allows the following which calls for type inference to bind the type name W appropriately. 

{ DEF twice OF W [F[x:int]:int] [Return[f[X:int]:int] :W]:W 
{ ReturnfFfFfX}}} }; 

twice{x*x]-; # i.e. F is x -> x*x with implicit x 
{f{2}} # so f{2} is 2-> {2*2}*{2*2} 

} 


in this case with the same result, but now f {2} can be replaced by something like stdout « f{2} << nl 
of type Output. 

INTERPRET is the name of a special operation that interprets an expression in context, 
as for instance in a nested read-eval-print-loop 

DEF twice DF W [F[x:int]:int] [Return[f[X:int]:int] :W]:W 
{ ReturnfFfFfX}}} } 

{ twice{x*x]- # i.e. F is x -> x*x with implicit x 

floopflNTERPRET}} # expresses a read-eval-print-loop 

} 

so that an input of f{2} will return 16. 

An operation, defrule, dehned internal to the interpreter can be used to generate 
lATEX-text for inclusion in documentations, and in this case def ruleftwice"} has been 
used to for the manuscript to include: 

twice OF W 

[F[x: int] : int] 

[Return[f[X:int]:int]] 


^t»ice{£:F}{^Return}^’ 


H 




1 Returning^ ^Return 


twice 

3^9. = 3d^9 
3 


^ [ 3x0. 


= 3n,e. 
= 3,X0. 


7.1 Details: Specialising operation twice 


The computational dehnition of twice is known and can be used to derive a rule for 
application of twice. The idea is similar to the projection of a function of pairs of values 
by keeping one fixed. 

Substitution of Return{F{F{X}>} for twice and the consequential F{F{X}} for Df gives 


^t»ice{£:F}{^Return}^’ 3 Feturn{F{F{X}}} 0- 






3Return{F{F{X}}}0- - ^ . 3 

3f{£x}0- 
. ^ [ 3x0. 

— 3f{f{X}}0. 

= 3ix9l . 
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Recall that elipsis denote memorised presumptions. We can instantiate the hrst presump¬ 
tion twice, once with F-[X}- and once with X substituted for Dx'- 


Rwice{£p}{£:Return} 


9. = 3 


Return{F{F{X}}} 


9. 


H 


3f{f{x}}^- = 3e^9. H [ = 3e{x}9. 

3J. = 3^9. 


3f{x}^- — 3e^9. 

The two rules can now be combined to one as in 

3twice{£p}{£:i^eturn}^‘ ~ 3 Returii{F{F{X}}} 


H 


1f{f{x}} 


9. = 3e,9. 


3^9. = 3f{x}0. 
3f{x}^- = 3 ep 9 . 


3.9. = 3^9. 


This rule can be simplihed by use of the third presumption to 

9. 


3twice{£:F}{£:Feturn}^‘ ^ 


^Retu 


H 


3f{F{X}}^- — 3 ep 9 . 


3.9. = 3Frvi6*. 


3f{x}^- — 3 ep 9 . 


F{X}t 


3.9. = 3^9. 


The bottom two presumptions can be combined to eliminate 3 f{f{x}}^- , and at the same 
time drop the two presumptions at the top: 


3 t.wi 


twicel^F }{^Return} 


9. = 3 


^Retu 


9. 



X 

m 

X 

m 




3f{£x}^- = 3 £f^- 3 

3x9. = dFlxj^*- 





_ 3f{x}^- = 3ep9. 3 

3J. = 3^9. 




H 


Finally the presumptions of the presumption can be combined so that every explicit refer¬ 
ence to the dehning context gets eliminated: 


3twice{£:F}{£^Return} 
H 


^• = 3£p, 9. 

■^Return 


3 f{Fx}^' = 3 ff^- 3 


3 . 9 . = 3 ep 9 . 


3.9. = 3eJ. 


Applications of operation f in ^Return is the given by the rule 

3 


’fRx}^- = ^Ep9. 3 


3J. = 3 ep 9.3 


3.9. = 3e^9. 
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So for any int-constant c we have 
3f{c}6'. 


3 . 0 . = 3 . 0 . 


3xri.3.r2. [0 < (ri x T 2 )] 3 

3 

x0- = 3.*.0. 3 

. 3.0. = 3.0. 


3x*xTi.3.*xT2. [0< (Ti X T 2 ) 

3 

. 3.0. = 3.0. 




= 3.^1.3x^2- [n O (;Ui X ;U 2 )] 3x/i5.3x/r6- [t2 o (h3 X Hi)] [0 <1 (ri x T 2 )] 


H 


3.0. = 3.0. 


= 3.//i.3./i2- [n <1 {Hi X /U 2 )] 3c/i5.3./i6. [r 2 <1 {Hs X yU 4 )] [0<l (Ti X T 2 )] 
= [0 < (c X c) X (c X c)] 


8 Sideeffects 

While a program is being developed, programmers sometimes need to add code to reflect 
progress (read: problematic behaviours). Mostly it amounts to what is known as ‘side- 
effects’ because it really illustrates that programs differ from mathematical expressions in 
kind. 

An illustration from an application of operation twice with a read-eval-print-loop is 

•demo 1> {var t; t:=0; ffstdout « ~"Step " << t:=t+l « nl; 2} }; 

Step 1 
Step 2 
Step 3 
Step 4 
16 

which reveals that the argument of operation f is ‘computed’ four times to arrive at the 
result 16, as postulated earlier. 

This is actually reflected in the rewriting to evaluate f{c} in the previous section: the 
step prior to the last contains 3./^^. for k=l-4. Obviously this is a point where efficiency 
can become important, and hence makes a need for means to avoid such repetitions. In 
other words: a need for call-by-value arguments. 

Arguments for which no name is introduced implicitly are the points where the issue 
of such side-effects may arise. The term call-by-name is used when such an argument is 
computed whenever the interpreter refers to it. A companion term is call-by-value which 
implies that a single reference is used to obtain the argument’s value, which is then saved 
for later use. 

The complete syntax of signatures allows call-by-value to be requested, but notice that 
it is a programmer’s responsibility to meet such requests. The actual syntax is simply 
to allow parentheses instead of brackets around a typed signature. In the example all 
brackets could be replaced by corresponding parentheses. Operation with evaluates its 
hrst argument as a value and passes it to its second argument. 

The following dehnition and its use illustrates how call-by-value can be achieved 
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2> DEF twice OF W [F(x:int):int] [Return[f(X:int):int] :W] : W 
3> { Return{with(X) u; F{F{u}}} } 

4> { twice{x*x} # i.e. F is x -> x*x with implicit x 

5> {loop-CiNTERPRET}} # similar to loop-eval-print 
6 > }; 

. 1> {var t; t:=0; f{stdout << ""Step " « t:=t+l << nl; 2} }; 

Step 1 
16 

More serious problems are that requests for call-by-value should be reflected in the seman¬ 
tics of an internal dehnition, and that means to express it should be found. The problems 
have been solved, as illustrated in the following subsection. 


8.1 Call-by-value vs. call-by-name 

Operation defruleC "twice") generates the manuscript for the following display after the 
signature has been changed: 


twice OF W 

[F(x:int):int] 

[Return[f(X:int):int]:W]:W 


Twice{£:F}{£:Return} 


e. = 3n . e. 

^twice 


H 


= dnxhi- [a; < hi] ^E^O. 


^ Returii{l?f } 


= ^fReturn^- ^ 




9. 


BEyrT]!- 


First note the use of parentheses instead of brackets in the signature. Second note that Dx 
on the right-hand side in the conclusion of the hrst presumption tells that the mathematical 
expression bound to the rji is substituted for x once and that such an expression cannot 
contain side-effects. Of course this implies that the previous description of the __ {__} 

is incomplete and the complete version has been implemented in the tool. 

It makes a nice exercise for readers to specialise the above rule for dehnition of twice 
to a rule for applications of twice until the following point is reached: 


3 

3 


twice{x*x}{f {c}} 3f|c}0. 

= ^E^Vl- <lhl] 

3f{F{X}}^- = 3F{x}hl- ^ hi] 3x*x^- 

_ 3f{x}6'. = 3x?7i. [ai<i? 7 i] 3x*x6'- 


The next step is to use the presumptions by equational reasoning: 


3f{c}6'. = 3 c?7i. [X <r]i] 3f{f{x}}6'- = 3c?7i. or/i] 3F{x}hi- [x<'ni] ^x*x9. 

Now we face a situation where substitution is tricky. The rji in [X < ?]i] is a free occurrence 
that will become bound if the substitution is done thoughtlessly, since every occurrence 
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of rji is bound by 3 f{x}^i-- The problem is overcome by renaming (i.e. the rule called 
a-conversion in the lambda-calculus). Thus we may proceed 

• • ■ = 3 c 772 - [3^ <r] 2 ] 3f{x}??i- [x<r]i\ 

= 3c772- [X<r] 2 ] 3x7^3- [x<m] 3x*xhl- [x<Vl] 

= 3^r]2. [X <772] 3 x? 73- [x<r] 3 ] [r]i <{x x x)] [x<r]i] [0 <1 (x x x)] 

= 3c772- [3^ < 112 ] 3x??3- [x<ir]3] [6'< ((x x x) x (x x x))] 

= 3 c? 72 . [3^ < 772 ] [0 < {{X xX)x{Xx X))] 

= [9 < ((c X c) X (c X c))] 

Enough details have been presented so that a careful reading will show where renaming is 
required to avoid unintended name bindings. 


9 Verification 

Program verification implies application of the transformation rules along with some ex¬ 
pression that may be a predicate. Rules can be identical to familiar rules introduced by 
others, e.g. Hoare’s rule for assignments. A rule for use of operation induction, cf. page 12 
matches proof by mathematical induction. Side-effects are essentially described like assign¬ 
ments to hidden variables. 

Two examples follow to illustrate (a) elimination of program variables and (b) informal 
verihcation based on equivalence of program fragments. 


Elimination 

Hoare’s rule for assignments is: 3x:=£'^. = [x<id]. Right-to-left progress implies 

that an expression using variable x in the state just after its initialisation can be 
quite complex but have the form 8x- Initialisation implies that x gets substituted 
by some expression, often a constant, so that x gets eliminated from the resulting 
mathematical expression: [x < e] 

Induction 

Mathematical induction proves 


(3 


induction(n) i:{if (i=0,0(2*i-l)+result 


= E”.„(2i - 1) 
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Equivalence 

A slight variation of the previous example is 




^ var x{x:=0; induction(n) i:{if(i=0,x){result(i-1); x:=2*i-l}};y:=x} 

which transforms to 

[x <1 0] 3 induct ion (n) i : {if (i=0 ,x) (result (i-1) ; x: =x+2*i-l}}^'3 x^- [l/ ^ 

With the presumption as induction hypothesis we can prove 

3result(k)^- 3 imjuctionCk) i : (if (i=0,x) (result (i-1) ; x: =x+2*i-l}} 


H 


and conclude: 


J result( 


a,e.= 0<(x + S^^o(2j-l)) 


H 


i < k 


( 6 ) 


VtI. 3 induct ion (n) i : (if (i=0,x) (result (i-1) ; x: =x+2*i-l}} X Ej_g (2i 1) 

The entire expression 6 then becomes 

[x <] 0] [0 <] (x + - 1))] [x <9][y<9]V 

which hnally can be reduced to 

[9 - 1)] [x<9] [y<i9]V 

so X is eliminated but its hnal value may survive elsewhere in the context. 

A more efficient computation results, if application of induction is replaced by an 
equivalent application of while. The rule for the former is the familiar and obvious, 
and the path followed here might be useful in other situations. 

Detailed inference rules have not been presented, for brevity and because this should not be 
considered an advocacy for specihc operations. But hopefully the examples are illustrative 
anyway. 


9.1 Partial and total correctness 

With rules as presented, programs as proofs can justify partial correctness only, i.e. proofs 
presume program termination. So a separate proof of termination is required. 

With generated transformation rules, termination is ensured only if every program 
step terminates, so one may have to add manually presumptions to ensure termination. 
Sometimes that requires knowledge about a specihc application domain. 

Signatures may exist for operations that belong to a specihc held of applications. An 
example is presented later and concerns unix-style process control (see page 20). Termina¬ 
tion properties with the chosen ‘members’ are complex and it may be impossible to reduce 
them to the usually known techniques for proofs of termination. A better design may, 
perhaps, encapsulate the problem. 

Howard languages are adequate as domain specihc languages, and the issue of termi¬ 
nation has to be delegated to specialist from the application held. How to help a specialist 
design operations with appropriate termination properties is an open question. 
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10 Components and their composition 

The notion of a component in this context is delightfully easy and general: 

A component is a named operation with a signature 

It means that the notion of a named operation is very broad, covering simple functions, 
structured statements, class-like entities, members that are operations, and generalised 
classes with several arguments each with own members. 

Composition is the same for all kinds of operations and corresponds to function composi¬ 
tion in the simplest case and statement composition otherwise. Implicit name introduction 
and the simple notion of types as sets have been essential for this simplihcation. Sets of 
functions are thus not admitted. 

Transformation rules for internal definitions are expressed in terms of unknown program 
fragments. Each application implies a binding of unknowns to actual fragments and thus 
makes specialisation possible. Transformation and evaluations work in opposite directions: 
the former right-to-left the latter left-to-right. 

Design of components can be a complex task. But a strict regime as represented by 
the requirement of a signature (as presented) for every component tends to help in design. 

One thing is components of a single program, another components of collections of 
programs. Experiences tells that a collections of programs may be connected by channels, 
e.g. POSIX pipes. Texts sent over a channel can be interpreted as program expressions in a 
context at the receiving side. One important predehned operation supports this behaviour 
in an actual interpreter. 

10.1 UNIX-based control operations 

An operation unix has been implemented with a signature shown in Box 3. The names 
PIPE and PID are member names of types, i.e. fresh types that should not be confused with 
others, not even the same in another unix-application. 

Member run is an example of a complex member that can be used class-like. It is used 
to invoke programs in separate processes and connect them in various ways, e.g. with pipes 
or to files. In terms of low-level primitives, the second argument of run has to describe 
how file descriptors are used as ports for interconnections. 

A typical programming error with UNIX which prevents termination of a process control 
program, is failure to close a pipe for which a controlled process expects an end-of-£le 
condition to arise. A designer may strive to define a complex operation so that disciplines 
to guard against such errors are enforced. 

10.2 Sorting 

It has been claimed that operations may be class like, and that the notion of classes may 
be generalised and have more than a single argument where members are introduced. It 
seems not to be widely needed but please note: 
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Box 3 Signature of operation unix 
Unix 

[Members OF PIPE, PID 
[newpipe:PIPE] 

[child[Init[exec(arg:string Array)]]:PID] 
[mk_stdin(x:PIPE) ] 

[mk_n(x:PIPE)] 

[mk_stderr(x:PIPE) ] 

[source OF W 
(x:PIPE) 

[Access(in:Input, _:Input):W]:W] 

[dest OF W 
(x:PIPE) 

[Access(out:Output, _:Output):W]:W] 

[close(x:PIPE)] 

[kill(p:PID)] 

[await(id:PID):int] 

[await_all] 

[run(Cmd:string Array) 

[Con OF 10 

[<(NONE,string) : 10] 

[>(NONE,string) : 10] 

[>>(NONE,string) : 10] 

[<(NONE,PIPE) : 10] 

[>(NONE,PIPE) : 10] 

[<(NONE,Input) : 10] 

[>(NONE,Output) : 10]:10 List]]] 


• Some languages have a predefined operation sort that distinguish an input and an 
output phase. An operation can be defined with an argument for each phase, one 
with an put-operation, another with an operation to receive elements after ordering: 

sort OF T,W 

[ InOrder [x:T][y:T]:int ] 

[ Send [put[X:T]] ] 

[ Receive [all[Body[x:T]]]:W] :W 

The first argument allows users to specify an ordering, e.g. as x<y. 

• There is a nice symmetry between the dehnition and application parts of an internal 
dehnition. So an internal definition can itself be considered an operation with two 
arguments with different ‘member names’. 
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• Class-like operations are defined in terms of an argnment name that defines meanings 
of members by an application of a name to many argnments. An example is the 
Sc ope-argument of operation var. A virtual internal dehnition would use the pattern 
(with labels as reminders before each argument): 

Scope _ {...} asg { ... } 

11 Conclusions 

The verb ‘to prove’ is transitive, but it is possible to conceive the noun ‘proof’ independently 
of an object as required by the verb. A proof can be understood as a pattern of references 
to individual rules of a formal logic. In that sense a program can be seen as a proof provided 
each construct used in the composition of a program has a unique proof-rule associated 
with it. A foundation to build a programming language with just such operations has been 
presented. 

A beneht of programs as proofs is that not all programmers need to master the logic 
aspects of programs completely. One may still acknowledge programmers work as proofs 
in a substantial sense. Designers should, of course, be more concerned with the rules for 
application of their operations, i.e. their adequateness as axioms of a logic. 

Another beneht might be the implicit enforcement of a programming discipline that is 
indirectly inhuenced by formal logic, much the same as discussions in daily life may beneht 
from rules justihed by formal logic. 

Howard languages have operations that identify axioms, even if not explicitly expressed 
in a description. Hence one might extend the Curry-Howard correspondence by considering 
a specihc Howard language as a theory. 

A traditional proof of a program is merely a proof check that the given proof is ehective 
in a given context. Failure might stem from an incomplete case analysis, and that might 
lead to useful feed-back to programmers. 

A programming language with constructs that all have signatures and hence possibly 
an internal dehnition rightly deserves to be called modular. New constructs can be im¬ 
plemented independently and added to extend existing languages. So languages and their 
semantics can be built incrementally. 

With the very broad notion of operations, it is easy to develop components by separate 
teams, if only they agree on component signatures. The intended semantics can and should 
be negotiated between teams from the outset and revised during development with cost 
estimates of changes. 

Concepts about programming languages, semantics, and logic in the sense of transfor¬ 
mation rules stem from previous work on a statement-oriented approach to data abstraction 
[6]. For programming practice it seems to be a realistic realisation of programs as proofs. 

Experimental tools have been developed to support programming language design, in¬ 
terpreter construction, and formalised documentation of semantics of operations. The tools 
also help to incrementally implement and install new operations with given signatures as 
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predefined entities. 

The programs-as-proofs aspect of the Curry-Howard correspondence is corroborated by 
this work. The propositions-as-types aspect only to a lesser degree. One can illustrate this 
with an expression outline 


3p0 : T.Re 

making it clear that T and Rg have different roles. Although it might be tempting to have 
T express the set of primes (or even subsets of primes) it seems simpler to keep the notions 
apart. Not the least with regard to acceptance by programmers. 

Mathematicans rarely rely on fully formal proofs, but formally state their goals. So 
perhaps one might say: programmers rarely rely on formally stated goals, but formally 
state their proofs as programs. 
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